Portable computer hosts, including handheld computing devices, notebook-sized computing devices, and similar reduced form-factor computing platforms, typically allow for expansion capabilities via slots for plug-in expansion cards (also known as expansion modules). Users of these portable hosts are hindered from realizing the full capability of the portable host without expansion cards, and typically users purchase a multiplicity of cards to use in various hosts for multiple applications. Users are unable to use these expansion cards in a “plug and play” fashion unless the cards are compatible with the software drivers included on the particular portable host at the time of manufacture of the portable host. Alternatively, users may directly install new drivers or configuration software that in turn installs new drivers, when a new expansion card is installed in a host for the first time. This driver installation effort reduces the utility of new expansion cards.
Current manufacturers of expansion cards for portable hosts respond to this need by supplying “plug and play” cards compatible with the insertion detection and automatic driver installation and activation provided by the standard software environment of many of these portable hosts. After insertion of the card into the expansion slot the host will query the card. A portion of the “plug and play” compatibility requires the card to then provide the host with card configuration information in a standard format. The returned information is in the format of a complex data-structure describing the capabilities and protocol requirements of the expansion card. This configuration information is the same for all instances of a given version of a card, but will likely differ for different card versions, and is certainly distinct between card designs of differing capabilities. A memory-only expansion card, for example, returns configuration information to the host that is dramatically different from a combination memory and I/O expansion card.
Expansion card designs have typically relied on an integral serial EEPROM component to provide non-volatile storage for the configuration information data returned to the host. Heretofore, it has been necessary that the EEPROM be initialized with the proper data before the first use of the card by an end-user.
Expansion Card Standards
Two of the most popular industry standards for expansion cards and their associated expansion slots are the PC Card and the CompactFlash (CF) Card. The PC Card has a 16-bit variant, previously known as a PCMCIA card, and a newer 32-bit variant, also known as a Card-Bus card. U.S. Pat. No. 5,815,426 ('426), ADAPTER FOR INTERFACING AN INSERTABLE/REMOVABLE DIGITAL MEMORY APPARATUS TO A HOST DATA PART, assigned to Nexcom Technology, and hereby incorporated by reference, describes these and other removable expansion card and memory types suitable for portable hosts. In addition to the PC Card and CF Card formats, the '426 patent includes discussions of and references to Miniature Cards, Sold State Floppy Disk Cards (SSFDCs), MultiMediaCards (MMC), Integrated Circuit (IC) Cards (also known as Smart Cards), and Subscriber Identification Module (SIM) Cards.
The following additional references provide further information on the PC Card and CF Card standards.
CFA, CF+ and CompactFlash Specification, Revision 1.4, www.compactflash.org, CompactFlash Association, P.O. Box 51537, Palo Alto, Calif. 94303.
CFA, CF+ and CompactFlash Specification, Revision ATA Compatibility Working Group Draft 0.1, www.compactflash.org, CompactFlash Association, P.O. Box 51537, Palo Alto, Calif. 94303.
PCMCIA, PC Card Standard, March 1997, www.pc-card.com, Personal Computer Memory Card International Association, 2635 North First Street, Suite 209, San Jose, Calif. 95134.
Design Guidelines for PC Card and CardBus, Addendum to PC 2001 System Design Guide, Version 1.1, Apr. 12, 2000, Intel Corporation and Microsoft Corporation.
Card Information Structure (CIS) Data Format
All PC Card and CF Card hardware interfaces to host application software via an intermediate two-layer interface: card services and socket services. The socket-services layer communicates directly with the expansion card socket-controller chips, and acts as an interface between this card socket-controller hardware and the card-services layer. The card-services layer manages the system resources the card requires, including determining IRQs and memory addresses allocated on the host for operation with the card. These software layers rely on obtaining information about the functions and characteristics of the expansion card by referencing a standard data-structure for card attributes, the Card Information Structure, or CIS. The CIS data describes the operations and capabilities of the card to the card and socket services software layers. The CIS data-structure is allocated to the lowest addresses in the standard expansion card attribute memory space.
The PC Card Standard defines a Card Metaformat that establishes CIS data-structure format rules. The standard CIS data-structure format is illustrated in FIG. 1A. The CIS is a collection of sets, called tuples, accessible in the attribute memory space of an expansion card. The CIS portion of the attribute memory is thus also known as the “tuple space.” Each tuple has a variable number (i.e., an n-tuple) of attribute parameters that are related in some way. Except for the final tuple, each tuple begins with a one byte code, followed by a one byte length, and ending with a variable number of data bytes. The length byte describes the number of data bytes. The number of tuples varies from card to card, and the end of the list is indicated by a special “last tuple” (CISTPL_END) having the code FFh. Thus, encountering a tuple beginning with FFh indicates there are no further tuples to process. No length or data bytes are required for the CISTPL_END tuple.
As illustrated in FIG. 1A, CIS Code1 (CD1) 105 is the code byte for CIS Tuple1 (TPL1) 100, the first tuple in the CIS. The next byte, CIS Length1 (LNG1) 106, is equal to the length of CIS Data1 (DT1) 107. The CIS Data1 107 provides the detailed descriptive information associated with CIS Code1 105. Following CIS Data, 107 is CIS Code2 (CD2) 108, the code for CIS Tuple2 (TPL2) 101. The length byte for Tuple2 101 is not explicitly shown, but is understood to be present as previously described. Similarly, DT2 109 is the is the detailed descriptive information associated with CD2. The special tuple marking the end of the CIS is CIS TupleN (TPLN) 103, with CIS CodeN (CDN) 110. (Since this is the last tuple, CDN must necessarily have the value FFh as discussed above.) Other tuples (OTPLS) 102 may be intermediate between TPL2 AND TPLN.
A particular tuple of interest defined by the PC Card Standard is the Device-Information Tuple (CISTPL_DEVICE) having the code 01h. This tuple is used to describe various types of Common Memory space within a PC Card. Sub-components of the device-information tuple include a type flag, a write protection flag, a speed field, and a size field. One particular defined type of interest for the device-information tuple is a null device (DTYPE_NULL, 00h), corresponding to the situation when no device is present at a corresponding portion of the Common Memory address space. The smallest size value allowed is 00h, which allocates 1 block of 512 bytes. In accordance with techniques known to those skilled in the art, the device-information tuple may be used (in conjunction with other tuples) by host driver/services to generate a unique Plug and Play device ID for the PC Card.
Serial EEPROM and UART Standards
Serial EEPROMs using a standard “three-wire” interface are known in the art. A representative part is the 93CS46, described in the datasheet for the NM93CS06/CS46/CS56/CS66 device, August 1994, from National Semiconductor.
Universal Asynchronous Receiver/Transmitters (UARTs) are also known in the art. The 16C450/16C550 is a de-facto standard for PC compatible serial ports. A representative part is described in the datasheet for the PC16550D, June 1995, from National Semiconductor.
Limitations of Previous Approaches
Expansion cards for use in portable hosts have been limited to providing data-structure configuration information from a serial EEPROM on the expansion card. Furthermore, the tuple space of this EEPROM has heretofore been fully programmed before the card is first mated by an end-user with a host. The serial EEPROM device required on the card, and the prior tuple space programming of the EEPROM by the expansion card manufacturer or vendor, add to the complexity and cost of the expansion card. This approach is also inherently inflexible, as once the tuple space is programmed the card can only be used for purposes consistent with its programming. This requires programming cards according to the intended end-use application, limiting the cards commonality with respect to end-uses. The EEPROM must also be interfaced to the host, using resources that might otherwise be available for other functions. Programming the EEPROM's tuple space before the first use of the card also reduces the options in the manufacturing flow producing the card, since the programming must be completed before the card may be used with a host. What is needed is an improvement that reduces the complexity, cost, and inflexibility of the current approach of using an EEPROM with a fully pre-programmed tuple space to provide the initial CIS.